然後就被擋了。

「高安全性 WAF vs 自動化模擬瀏覽器」
一般的自動化工具（像 curl、Python requests、Acunetix 或 Burp 的簡單模擬）雖然能送出正確的 HTTP request，但它們的 fingerprint（指紋特徵） 與真實瀏覽器還是有差異。
WAF 如果設定嚴格，就會檢查這些差異並阻擋。

WAF 偵測/阻擋 fingerprint 的方法：

1. TLS/SSL Fingerprinting（JA3 / JA3S）
   真實瀏覽器（Chrome、Firefox、Safari）的 TLS 握手有獨特的 ClientHello 指紋，例如 Cipher Suites、Extensions 順序。
   自動化工具常用的 OpenSSL 或 curl，JA3 值會與真實瀏覽器不符。
   嚴格的 WAF 可以比對 JA3 fingerprint，封鎖異常的 TLS handshake。

2. HTTP Header 分析
   真實瀏覽器會送出一套 固定順序 的標頭（User-Agent、Accept、Accept-Language、Upgrade-Insecure-Requests…），甚至大小寫與空格都很一致。
   模擬工具（requests、curl）通常會漏掉某些 header，或順序不正確。

嚴格 WAF 可檢查：
Header 出現順序是否異常
是否缺少「常見瀏覽器才有」的 header
User-Agent 與 TLS fingerprint 是否匹配（例如 UA 說是 Chrome 但 TLS fingerprint像 OpenSSL）

3. 行為式檢查（Behavioral Checks）
   正常瀏覽器第一次請求頁面時，會順便抓 favicon、CSS、JS。模擬工具往往只打一個 request。
   WAF 可以檢查「是否有後續資源請求」。若沒有，就懷疑是自動化。
   也能用 JavaScript 挑戰（例如生成一段隨機數字 token），確認 client 能正確執行 JS。

4. 瀏覽器環境驗證（Browser Integrity Check）
   Cloudflare、F5、Imperva 等進階 WAF 會用 JS/CAPTCHA 驗證：
   送一個隱藏欄位，必須靠瀏覽器執行 JS 填回來。
   驗證瀏覽器的 navigator 物件（像 plugins, languages）。
   模擬瀏覽器若沒有完整 DOM/JS 引擎，就過不了。

5. Cookie / Session 驗證
   發給 client 的 Cookie 有 HttpOnly / Secure / SameSite 屬性，正常瀏覽器會照規則送回。
   某些簡單模擬環境會處理錯誤或漏掉。
   嚴格的 WAF 可以比對 session token 行為異常時阻擋。